<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>The GenomeTools Development Contract</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<div id="menu">
<ul>
<li><a href="index.html">Overview</a></li>
<li><a href="https://github.com/genometools/genometools/releases">Releases</a></li>
<li><a href="pub/">Archive</a></li>
<li><a href="https://github.com/genometools/genometools">Browse source</a></li>
<li><a href="http://github.com/genometools/genometools/issues/">Issue tracker</a></li>
<li><a href="documentation.html">Documentation</a></li>
  <ul class="submenu">
    <li><a href="tools.html">Tools</a></li>
    <li><a href="manuals.html">Manuals</a></li>
    <li><a href="libgenometools.html">C API</a></li>
    <li><a href="docs.html"><tt>gtscript</tt> docs</a></li>
    <li><a id="current" href="contract.html">Development Contract</a></li>
    <li><a href="contribute.html">Contribute</a></li>
  </ul>
<li><a href="annotationsketch.html"><tt>AnnotationSketch</tt></a></li>
<li><a href="/cgi-bin/gff3validator.cgi">GFF3 validator</a></li>
<li><a href="license.html">License</a></li>
</ul>
</div>
<div id="main">
<h1>The <i>GenomeTools</i> Development Contract</h1>

<p>The <i>GenomeTools</i> Development Contract (GtDC) is a fork of the <a href="http://rfc.zeromq.org/spec:22">C4</a> of the <a href="http://www.zeromq.org">ZeroMQ</a> project, with
some sections removed and adjusted licensing terms.<br />
This is revision <b>0</b> of the GtDC (2013-07-04).</p>

<h2 id="toc0"><span>Language</span></h2>
<p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in <a href="http://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
<h2 id="toc2"><span>Goals</span></h2>
<p>GtDC is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:</p>
<ul>
<li>To maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;</li>
</ul>
<ul>
<li>To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;</li>
</ul>
<ul>
<li>To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;</li>
</ul>
<ul>
<li>To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;</li>
</ul>
<ul>
<li>To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;</li>
</ul>
<ul>
<li>To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.</li>
</ul>
<h2 id="toc3"><span>Design</span></h2>
<h3 id="toc4"><span>Preliminaries</span></h3>
<ul>
<li>The project SHALL use the git distributed revision control system.</li>
</ul>
<ul>
<li>The project SHALL be hosted on <a href="http://github.com">github.com</a> or equivalent, herein called the &quot;Platform&quot;.</li>
</ul>
<ul>
<li>The project SHALL use the Platform issue tracker.</li>
</ul>
<ul>
<li>The project SHOULD have clearly documented guidelines for code style.</li>
</ul>
<ul>
<li>A &quot;Contributor&quot; is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.</li>
</ul>
<ul>
<li>A &quot;Maintainer&quot; is a person who merge patches to the project. Maintainers are not developers; their job is to enforce process.</li>
</ul>
<ul>
<li>Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.</li>
</ul>
<ul>
<li>Maintainers SHALL have commit access to the repository.</li>
</ul>
<ul>
<li>Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.</li>
</ul>
<h3 id="toc5"><span>Licensing and Ownership</span></h3>
<ul>
<li>The project SHALL use the <a href="license.html">ISC license</a>.</li>
</ul>
<ul>
<li>All contributions to the project source code (&quot;patches&quot;) SHALL use the same license as the project.</li>
</ul>
<ul>
<li>All patches are owned by their authors. There SHALL NOT be any copyright assignment process.</li>
</ul>
<ul>
<li>The copyrights in the project SHALL be owned collectively by all its Contributors.</li>
</ul>
<ul>
<li>Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.</li>
</ul>
<h3 id="toc6"><span>Patch Requirements</span></h3>
<ul>
<li>Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.</li>
</ul>
<ul>
<li>A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.</li>
</ul>
<ul>
<li>A patch MUST adhere to the code style guidelines of the project if these are defined.</li>
</ul>
<ul>
<li>A patch MUST adhere to the &quot;Evolution of Public Contracts&quot; guidelines defined below.</li>
</ul>
<ul>
<li>A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.</li>
</ul>
<ul>
<li>A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.</li>
</ul>
<ul>
<li>A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.</li>
</ul>
<ul>
<li>A &quot;Correct Patch&quot; is one that satisfies the above requirements.</li>
</ul>
<h3 id="toc7"><span>Development Contract</span></h3>
<ul>
<li>Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.</li>
</ul>
<ul>
<li>To initiate changes, a user SHOULD log an issue on the project Platform issue tracker.</li>
</ul>
<ul>
<li>The user SHOULD write the issue by describing the problem they face or observe.</li>
</ul>
<ul>
<li>The user SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.</li>
</ul>
<ul>
<li>Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.</li>
</ul>
<ul>
<li>Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.</li>
</ul>
<ul>
<li>To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.</li>
</ul>
<ul>
<li>To submit a patch, a Contributor SHALL create a Platform pull request back to the project.</li>
</ul>
<ul>
<li>A Contributor SHALL NOT commit changes directly to the project.</li>
</ul>
<ul>
<li>To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.</li>
</ul>
<ul>
<li>To accept or reject a patch, a Maintainer SHALL use the Platform interface.</li>
</ul>
<ul>
<li>Maintainers SHALL NOT accept their own patches.</li>
</ul>
<ul>
<li>Maintainers SHALL NOT make value judgments on correct patches.</li>
</ul>
<ul>
<li>Maintainers SHALL merge correct patches rapidly.</li>
</ul>
<ul>
<li>The Contributor MAY tag an issue as &quot;Ready&quot; after making a pull request for the issue.</li>
</ul>
<ul>
<li>The user who created an issue SHOULD close the issue after checking the patch is successful.</li>
</ul>
<ul>
<li>Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.</li>
</ul>
<ul>
<li>Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.</li>
</ul>
<ul>
<li>Maintainers MAY commit changes to non-source documentation directly to the project.</li>
</ul>
<h3 id="toc8"><span>Creating Stable Releases</span></h3>
<ul>
<li>The project SHALL have one branch (&quot;master&quot;) that always holds the latest in-progress version and SHOULD always build.</li>
</ul>
<ul>
<li>The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.</li>
</ul>
<ul>
<li>To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.</li>
</ul>
<ul>
<li>Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.</li>
</ul>
<ul>
<li>A stabilization project SHOULD be maintained by the same process as the main project.</li>
</ul>
<ul>
<li>A patch to a stabilization project declared &quot;stable&quot; SHALL be accompanied by a reproducible test case.</li>
</ul>
<h3 id="toc9"><span>Evolution of Public Contracts</span></h3>
<ul>
<li>All Public Contracts (APIs or protocols) SHOULD be documented.</li>
</ul>
<ul>
<li>All Public Contracts SHOULD have space for extensibility and experimentation.</li>
</ul>
<ul>
<li>A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.</li>
</ul>
<ul>
<li>A patch that introduces new features to a Public Contract SHOULD do so using new names.</li>
</ul>
<ul>
<li>Old names SHOULD be deprecated in a systematic fashion by marking new names as &quot;experimental&quot; until they are stable, then marking the old names as &quot;deprecated&quot;.</li>
</ul>
<ul>
<li>When sufficient time has passed, old deprecated names SHOULD be marked &quot;legacy&quot; and eventually removed.</li>
</ul>
<ul>
<li>Old names SHALL NOT be reused by new features.</li>
</ul>
<ul>
<li>When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.</li>
</ul>
<h3 id="toc10"><span>Project Administration</span></h3>
<ul>
<li>The project founders SHALL act as Administrators to manage the set of project Maintainers.</li>
</ul>
<ul>
<li>The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.</li>
</ul>
<ul>
<li>A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.</li>
</ul>
<ul>
<li>Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.</li>
</ul>
</div>

<div id="footer">
Copyright &copy; 2007-2023 The <i>GenomeTools</i> authors.
Last update: 2011-02-11
</div>
</div>
</body>
</html>
